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Abstract — The authors describe challenging use-cases for 
Automatic Test Markup Language (ATML), and evaluate 
solutions. The first case uses ATML Test Results to deliver active 
features to support test procedure development and test flow, and 
bridging mixed software development environments. The second 
case examines adding attributes to Systems Modelling Language 
(SysML) to create a linkage for deriving information from a 
model to fill in an ATML document set. Both cases are outside 
the original concept of operations for ATML but are typical 
when integrating large heterogeneous systems with modular 
contributions from multiple disciplines. 
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I. Introduction 

A utomatic Test Markup Language (ATML) is an 
emerging standard that offers sophisticated markup and a 
modular framework for representing information needed to 
determine what tests to run and how to run them. ATML was 
developed to support sophisticated box-level (Unit Under 
Test, UUT) maintenance testing in the field, depot and at the 
factory. 

But the ATML Concept of Operations (CONOPS) is 
fundamentally built around transferable concepts that can be 
extended to other usages. The National Aeronautics and 
Space Administration (NASA) invests heavily in design, 
builds redundancy (the spare parts) in, but produces and 
maintains very small quantities. In this environment, the focus 
of testing is run-once, with some tests being repeated as the 
design is refined, or for record with production units. Tests 
can range from exploratory engineering evaluations to formal 
acceptances. Performance margins and anomalies discovered 
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during development tests will eventually be discussed with 
review boards, and the test outline may be reprioritised or 
expanded by the test team based on test outcomes during the 
ephemeral test opportunity. 

II. ATML Comes Alive 

NASA has demonstrated that ATML can be used in live 
message-passing, to describe and manipulate state variables in 
software elements controlling the testbed. [1] As we began 
composing procedures, we found that we needed additional 
metadata for the state variables so that “arbitrary knowledge” 
about settings needn’t be learned by rote, and so that results 
can be used without assumptions or required conventions. In 
summary the ability to send enough information so that 
individual test results can be interpreted correctly and acted on 
without reference to any external context or knowledge. 

A. Multiple Ranges: Sets, Pick-Lists, Health, and Safety 
In the “pick-list” application, a script or procedure 
developer needs to discover the values to which a string 
variable can be set, and pick the appropriate value from the 
list. This means that the c:Parameter uses a c: Expected range 
associated with it, to carry this list, as the constraints of the 
value. As an example, we scripted a networked power 
controller which could respond to outlet states of {“OFF”, 
“ON”, “CYCLE”} (although it only reports {“OFF”, “ON”}). 
We found that the ATML Datum type was not conceived to 
define multiple ranges to express a set, however a reasonable 
accommodation exists, wherein the string is described by a 
collection of strings ( Figure 1 Figure 1 ). 

<c:Datum xsi:type="c:string"> 

I <c:Range name="valid"> 

j <c:Expected comparator="EQ"> 

<c:Collection> 

MM <c:ltemxc:Datum xsi:type="c:string"><c:Value>OFF</c:Value></c:Datumx/c:ltem> 
j <c:ltem><c:Datum xsi:type="c:string”xc:Value>ON</c:Valuex/c:Datumx/c:ltem> 
MM <c:ltemxc:Datum xsi:type="c:string"xc:Value>CYCLE</c:Valuex/c:Datumx/c:ltem> 
j </c:Collection> 

| </c:Expected> 
j </c:Range> 

| <c:Value>ON</c:Value> 

</c:Datum> 

Figure 1. c:Range Expressing a Set 

In this example, we gave the range the name “valid”, as it 
identifies the settings that are valid. Ranges can also be used 
to communicate how to interpret the setting or reading. 
Examples could be “high”, “mid”, “low”, “alarm”, “full”, 
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“empty”, “degraded”, “default”, “nominal”, “completed”, 
“safe”, “unsafe” or others. 

Data that is harvested through a tightly-coupled software 
application program interface (API) will often use an internal 
representation that needs to be translated for a user or a script 
developer. In Figure 2 Figure 2 , the switch states from Figure 
I Figure 1 are represented by an enumerated type. Here, the 
“name” attribute of the c:Item element is used to associate a 
functional meaning with these integer values. 

<c: Datum xsi:type="c:integer" value='T' > 

| <c:Range name="valid"> 

I <c:Expected comparator="EQ"> 
j <c:Collection> 

<c:ltem name="OFF"> <c:Datum xsi:type="c:integer" value="0"x/c:Datum></c:ltem> 
<c:ltem name="ON"> <c:Datum xsi:type="c:integer" value='T></c:Datumx/c:ltem> 
MM <c:ltem name="CYCLE"xc:Datum xsi:type="c:integer" value=' , 2"x/c:Datum></c:ltem> 

| </c:Collection> 

</c:Expected> 

</c:Range> 

</c:Datum> 

Figure 2. c:Range Expressing a Set, with c:Item@name 

In our scenario, each operator is controlling many software 
elements, and each of those software elements could be 
controlling hardware elements. It has been a long standing 
need of ours to inform the operator of elements that are 
missing or degraded. Last year we suggested enforcing 
conventions [2] for health and safety indicators. But 
constraints that are easy to meet for one development 
environment are challenging for another tool. Arbitrary 
constraints can be eliminated by instead taking a data-driven 
approach, providing markup to describe what “healthy” is or 
what “safe” is (and observe, these ranges need not be 
orthogonal). 

ATML attaches a named range to a Datum — but only one; 
consider the range name as the range classification to which 
the value belongs. It was not conceived that a “valid” range, a 
“safe” range, and a “healthy” range would all be provided; the 
multiplicity is one. Although awkward and verbose, a 
technique was identified that validates against the existing 
schema. 

<c:Datum xsi:type="c:integer" value- ’-1 "> 

! <c:Range> 

I <c:Expected comparator="EQ"> 

I <c:Collection> 

| | I | <c:ltem><c:Collection><c:Range name =,, error"xc: Expected comparator= ,, EQ"> 
||||j <c: Datum xsi:type="c: integer" value="07> 

| </c:Expectedx/c:Range></c:Collection></c:ltem> 

MM <c:ltem><c:Collection><c:Range name="healthy"xc:Expected comparator="EQ"> 

| j | j j <c: Datum xsi:type="c: integer" value="-17> 

| | | | </c:Expectedx/c:Range></c:Collection></c:ltem> 

j j j { <c:ltem><c:Collection><c:Range name="valid"xc:Expected comparator="EQ"> 

| | j | | <c:Collection> 

| j j || | <c:ltem name="false"xc:Datum xsi:type= M c:integer" value= M 07x/c:ltem> 
<c:ltem name="true"xc: Datum xsi:type="c:integer" value="-17x/c:ltem> 

| | | | | </c:Collection> 

Mjj </c:Expectedx/c:Rangex/c:Collectionx/c:ltem> 

| </c:Collection> 

| </c:Expected> 

</c:Range> 

</c:Datum> 

Figure 3. c:Datum with Multiple Ranges that are Sets 

| In Figure 3 Figure 3 the software has an error condition if 
the value is 0, is considered “healthy” if the value is -1, and 
| the set (concept from Figure I Figure 1 ) of both 0 and -1 are 
“valid”. . We also used the name attribute of the c:Item 
| elements to communicate that the software environment uses 


an internal representation of 0 to mean “false” and an internal 
representation of -1 to mean “true”. The construct is curious, 
as nested empty c: Collection’s are used to carry the c: Range’s. 
But this construct also allows c:SingleLimit and c:LimitPair 
ranges to describe “healthy”, “safe”, and “valid” conditions. 
In Figure 4 Figure 4 the same construct is applied to a floating- 
point data type. In this example, the thermocouple is reading 
72.5° C. A “failed” thermocouple manifests by reporting a 
value of -20° C. The thermocouple can report readings in the 
(“valid”) range of -20 to 100, but readings outside the range of 
-10 to 80 are not “safe”. The “unsafe” range here illustrates 
using named sub-ranges (“unsafe. low” and “unsafe.high”) to 
not only classify a temperature reading as “unsafe” but 
provide further interpretation of what the unsafe condition is. 

<c:Datum xsi:type="c:double" value="72.5" standardUnit="°C"> 

<c: Resolution^. 01 </c: Resolutions 
<c:Ranges 

<c:Expected comparator="EQ"s 
| <c: Collections 

< c : It e rn > < c : C o 1 1 e ct i o n > < c : R a n g e name="failed"s 

<c: Expected comparator="EQ"> 

| | | | | | | | | < c : D at u rn x s i : t y p e= " c : d o u b I e " va I u e= "-20 "/> 

</c: Expect ed> 

</c:Range></c:Collection></c: Items 

< c : It e rn s < c : C o 1 1 e ct i o n s < c : R a n g e name="safe"s 

< c : Li rn it F' a i r o p e rat o r- "AN D " s 

| | | | | | | | <c: Limit comparator="GE"s 

< c : D at u rn x s i : t y p e= " c : d o u b I e " va I u e= 1 0 7s 

|| || || || </c: Limits 

| | | | | | | | <c: Limit comparator" LE"s 

| | | | | | | | | < c : D at u rn x s i : t y p e= " c : d o u b I e" va I u e= "80 7s 

| | | | | | | | </c: Limits 

! </c: Limit Pairs 

</c:Ranges</c:Collections</c: Items 
<c:ltems<c:Collections<c:Range name="unsafe"s 
<c: Expected comparator="EQ"s 
| | | | | | <c: Collect ions 

< c : It e rn s < c : C o 1 1 e ct i o n s < c : R a n g e name="unsafe.low"s 

| | | | | | | | | <c: SingleLimit comparator="LT"s 

| | | | | | | | | | < c : D at u rn x s i : t y p e= " c : d o u b I e " va I u e= 1 0 7s 

</c: SingleLimit s 

</c:Ranges</c:Collections</c: Items 

| | | | | | | <c:ltems<c:Collections<c:Range name="unsafe.high"s 

| <c: SingleLimit comparator="GT"s 

| | | | | | | j | | j < c : D at u rn x s i : t y p e= " c : d o u b I e " va I u e= "80 7s 

</c: SingleLimit s 

</c:Ranges</c:Collections</c: Items 
| | | | | | </c: Collections 

</c:Expecteds 

</c:Ranges</c:Collections</c: Items 

< c : It e rn s < c : C o 1 1 e ct i o n s < c : R a n g e narne="valid"s 

< c : Li rn it F' a i r o p e rat o r- "AN D " s 

| | | | | | | | <c: Limit comparator="GE"s 

< c : D at u rn x s i : t y p e= " c : d o u b I e " va I u e= "-20 7s 

| | | | | | | | </c: Limits 

<c: Limit comparator" LE"s 

| | | | | | | | | < c : D at u rn x s i : t y p e= " c : d o u b I e " va I u e= " 1 00 7s 

| | | | | | | | </c: Limits 

! </c: Limit Pairs 

</c:Ranges</c:Collections</c: Items 
</c : C o 1 1 e ct i o ri s 
</c:Expecteds 
</c:Ranges 
</c:Datums 

Figure 4. c:Datum with Multiple Ranges using Limits 

B. tr:TestResults as a Status and Control Document 
The tr:TestResults document construct can be used to 
describe a software configuration and status snapshot during a 
live operation ( Figure 5 Figure 5 ). This enables a data-driven 
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data harvest from source-points in ATML format, rather than 
collection in one format and later conversion to ATML. 

1 <tr:TestResults xmlns:tr="urn:IEEE-1636.1 :201 1 :01 :TestResults" xmlns:c="urn:IEEE-1671 :2010:Common" xmlns:sc=" 
urn: IEEE-P1 636.99:01 :SimicaCommon" xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" xsi:schemaLocation 
="urn: IEEE-1 636. 1:201 1 :01 :TestResults TestResults.xsd" uuid="{589B634F-1 0F6-481 e-AD22-71 150201 55BF}"> 

<tr: Personnel 

j <tr:SystemOperator ID="jdoe1 "/> 

</tr:Personnel> 

<tr:ResultSet ID="_f47ac10b-58cc-4372-a567-0e02b2c3d479" name="BERT.vi" startDateTime="201 2-05-30709:30: 10"> 

| <tr: Outcome value="Aborted"/> 

© | <tr:Test ID="_6ba7b810-9dad-1 1 dl -80b4-00c04fd430c8" name="my Space-to-Ground Link" startDateTime=" 
20i2-05-30T09:30:io n > 

O || <tr:Parameters> 

| <tr: Outcome value="Aborted'7> 

O || <tr:TestResult ID="_1" name=“bits"> 

O I | <tr:TestResult ID="_2" name="errors"> 

O || <tr:TestResult ID="_3" name="BER"> 

O || <tr:TestResult ID="_4" name="Time to Acq"> 

O <tr:TestResult ID="_5" name="Online"> 

O <tr:TestResult ID="_6“ name="Connected"> 
i i <tr:TestResult ID="_7" name="HW Status"> 

</tr:Test> 

</tr:ResultSet> 

© <tr:TestProgram> 

© j <c:Definition version= ,, MyVersionOrRevisionNumber"> 

© j | <c: Identification designatoF"My Operator- or Model-supplied identification of instance test-point, configuration 
diagram designator, usage, or meaning- assigned after start-up"> 

| <c:Version>MyRevisionHistory</c:Version> 

| <c:ModelName>MyApplicationName</c:ModelName> 

| </c:ldentification> 

■ | </c:Definition> 

| <c:SerialNumber>MylnstanceUUID</c:SerialNumber> 
i <c:ReleaseDate>2011-12-02</c:ReleaseDate> | 

• </tr:TestProgram> 

L </tr:TestResults> 

Figure 5. tr:TestResults Document Structure 

In such a document, tr: Parameters section is used to 
describe the configurable (input) parameters, while 
tr:TestResult is used for measurements and status (output) 
parameters. tr:TestResult and tr:Parameter do not offer 
identical metadata. Internally tr:TestResult uses the 
tr:TestData extension of tr:Data which has the sole variance of 
an added acquisitionTimeStamp attribute added to the c: Value 
type, while tr:Parameter itself has a timestamp attribute. Also, 
the ID attribute of tr:Parameter is a c:NonBlankString, 
whereas the ID attribute of tr:TestResult is a more restrictive 
xs:ID. And a tr: Parameter cannot have a tr: Trans form or 
tr:Extension, which could be useful for converting between an 
internally useful representation and an externally useful 
representation. tr:TestResult also offers optional tr: Outcome, 
tr:Indigtments, tr:TestLimits, and tr: Extension, differences we 
considered incidental. 

Placing a tr:Test construct inside of tr:ResultSet is optional. 
We have used this additional metadata to identify role (test- 
point) of the software in the context of the test. 

One must eventually conclude that tr: Outcome must be 
“Aborted”, as it is neither “Passed” nor “Failed”. 

The tr:Personnel construct allows the user of the software or 
host to be recorded with the data. It also could allow a user to 
take responsibility for manually inspecting the configuration, 
by creating a record using the tr:QualityAssurance element. 

We also observed that in the dynamic environment of a 
development test, experimentation with algorithms can occur 
and the software version itself becomes a test variable. 
tr:TestProgram uses a c:SoftwareInstance, which has a 
c:ReleaseData of type xs:date. But in this situation, the 
timestamp on the software could change more than once per 
day. 

C. Implementation 

For demonstration, an implementation was developed in 


Lab VIEW which discovers the controls on a Virtual 
Instrument panel, then describes them in an ATML 
tr:TestResults document from properties configured by the 
software developer. This technique places minimal additional 
burden on the developer to produce a well-documented 
interface, and relieves the burden of maintaining the same 
software documentation in two formats (one in Lab VIEW 
control properties, and one in ATML). 

III. Deriving ATML from SysML 

In any multi-disciplinary high-performance design 
endeavour it is necessary to package information for 
subsystems while maintaining a clear depiction of the whole 
system and the environment it must operate in. In this context, 
ATML is part of a larger information ecosystem, and it needs 
to be exchanged between the tools of that ecosystem, not 
hand-generated. The information will have versions: original 
design, changed design, as-built... Throughout the process, 
information must be traceable to the authoritative source of 
information, and copies of information must be maintained 
synchronous. Traditionally, this was enforced by manual 
reconciliation of branches. Here we explore the simplest 
automation, regeneration of information packages from single 
authoritative sources. 

The ATML CONOPS employs standardized test sets. Test, 
maintenance, and diagnostic strategies must be considered 
during the design phase, and this means that information about 
test requirements must be reconciled with information about 
fielded test assets at project Preliminary Design Review 
(PDR) [3], 

Remember, ATML is an information framework. The 
philosophy is, describe the requirements, describe the 
capabilities of the test set, describe the interconnections. This 
will allow different implementations and design abstractions 
to allocate resources, throw switches, run the test, and 
interpret the results. This data-driven approach does not 
require that every product use the same source code or 
development environment, only the same information. The 
respective curators of information supply the information they 
curate. Capabilities can be changed without rewriting 
software, if only the affected information is maintained. 

The Systems Engineering process has since the early 1980’s 
been portrayed using a “V” diagram ( Figure 6 Figure 6 ). The 
process progressively decomposes a problem from studies and 
concepts into requirements, subsystems, and components. The 
design is executed, and then progressively integrated and 
tested from components to subsystems, to system verification 
(against requirements) and validation (against concepts of 
operations). Finally it is deployed, with continuing support for 
breakdowns, feature changes, and upgrades, ending with 
retirement or replacement at obsolescence. 
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Figure 6. Systems Engineering “Vee” Diagram 


exercise was however useful for developing greater familiarity 
with both ATML and SysML. 

Thus we fell back to trying to create library components 
with standardized ATML-mapped attributes that might work 
more naturally in the SysML editor but represent ATML 
concepts. This approach could allow us to export constructs 
from SysML, and map test results back to SysML. 

C. Requirements 

The requirements diagram in SysML is an extension to 
UML. As such it is a less mature component. Requirements 
from SysML do not appear useful for automatic testing, as 
they have been implemented as human-interpreted “dumb 
text.” 


As Figure 6 Figure 6 suggests, different kinds of tools 
support the work of different phases. Systems Modelling 
Language (SysML) is an Object Management Group (OMG) 
standard sponsored by the International Council on Systems 
Engineering (INCOSE) and gaining acceptance as a method of 
expressing, verifying, and validating a system design prior to 
execution in hardware and software. SysML is a subset of 
Unified Modelling Language (UML 2) with extensions. [4] 
The object of using SysML is that the design can be verified 
against requirements (close the “V”) before implementation 
begins. Following implementation, the unit, subsystem, and 
system need to be verified (ATML) against the model 
(SysML), and characterization (ATML) fed back into the 
model (SysML). 

A. Implementation 

To explore potential approaches, MagicDraw was used as a 
SysML editor. A test configuration block diagram for a power 
converter was modelled as a test case. 

To derive an ATML document from a SysML model, 
information that will be loaded into the document must be 
provided in the model. This requires creating libraries of 
blocks and stereotypes with inheritable attributes. An 
ontology, or at least a naming convention, is required so that 
the relevant attributes can be located and interpreted. 

B. Literal or Abstract 

Our first, direct approach was to represent ATML 
constructs literally in SysML. ATML attributes could be 
expressed as properties of a UML stereotype, or of a SysML 
block. Points of confusion include when to use a stereotype 
and when a block, where to put the value of the ATML 
element, and how to handle an xml “choice.” It did not look 
possible for SysML properties to themselves have properties 
(corresponding to XML attributes). Further, placing and 
changing default information in these structures in SysML 
without instantiating them requires frequent use of 
redefinition, which is clumsy in the MagicDraw 17.0 tool. 
Further, ATML supports very complex structures for 
describing complex hardware, and these could be daunting and 
unnatural for a SysML tool user. Also consider, both ATML 
and SysML are at an intermediate stage of development as 
neither presently achieves alignment with any ontology. The 


D. Quantities and Units 

SysML ties units to QUDV, an ontology now used by OMG. 
Presently, only SI units are supported in QUDV, and 
MagicDraw only includes a subset of those. Units in ATML 
are relatively weak. 

ATML identifies some concepts that today’s ontologies 
overlook. These include the “unitQualifier”; although the 
usage of this field has not been standardized by IEEE, it is 
intended to associate a statistical method with the 
measurement. This is important when comparing 
measurements (for example, a signal measuring 2 V p-p can’t 
be compared directly to a signal measuring 0.7 V rms). But it 
could also be the key to data-driven data aggregation. When 
aggregating “peak-peak” values, report the maximum value. 
When aggregating “rms” values, take the rms of the values. 
ATML also enables the capture of Resolution, Range, 
Confidence, and ErrorLimits which are needed for comparing 
a measurement against a test requirement. For example, it is 
intended that, given a requirement to measure the power 
converter output voltage with a passing result between 24V 
and 32V, a reasoner could find an instrument capability in its 
inventory that can make the measurement with the necessary 
resolution, and then compare the measured result with the 
requirement. 
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■s stereotypes- 

atmlDatumGuality_c 

[Element] 

+Resolution : double [0..1] 

+ErrorLimits : atmll_imrt_c [0..1] 

+Confidence : atmll_imit_c [0..1] 

+Range : double [0..1] P ^-suses 


■k stereotypes 

atmIDatumTypec 

[Element] 

+value : atmlValueType_c 
J 

/ 

/ 


■k stereotypes 

atmlStandardUnit_c 

[Element] 

IT 

■suses 

\ 


/ 

■suses / 

/ 

/ 

/ 

/ 


i M, 

■k stereotypes 

atmlUnitAttributes_c 

[Element] 

+standardUnit : atmlStandardUnit_c [0..1] 
+nonStandardUnit : atmlNonBlankString_c [0..1] 
+unitQualifier : atmlNonBlankString_c [0..1] 


■sValueTypes 

atmlValueType_c 

statistic : atmlUnitQualifier_c 


■senumerations 


atmIUnitOualif iei_c 

mean 

rms 

peak 

peak-peak 
median 
percentilel 0 


Figure 7. Extending SysML for ATML Quantities 


The UML stereotypes shown in Figure 7 Figure 7 were not 
ultimately useful. The extended ValueType worked well in 
isolation, its value can be selected from the pick-list provided 
by the enumeration. It was not evaluated in a practical 
application. 


E. Connectors and Wiring 

bdd [Block] Power Controller [ Power Supply def JT 


Vin : powerCtrlr_EIF 
highside _i : V 


^blocks 

J : V pEp Power Controller 

constraints _ _J 

,j : yU 3 owerOutEqn 

^r-PowerFlow VJ 


constraints 
3 owerOutEqn 
Flow 

PowerlnEqn = (Pin=lin * Vin) 
PowerEfficiency 


AmbiTemp 


: C pZjwrlnConnect 

values 

: A{unit = ampere} 


Vout : powerCtrlr_EIF 
' highside_o : V 


.0 


lowside_o : V 


.WasteHeat : w 


highside _i : V 
lowside _i : V 


s 


«blocks 

powerCtrlr_EIF 


parts 

: Connector ACPowerPlug2 
: Connector ACPowerSocket2 


highside_o : V 
lowside_o : V 


highsidej : V{redefines power .unit = volt} 
lowsidej : V{redefines neutral .unit = volt} 
highside_o : V{redefines power .unit = volt} 
lowside_o : V{redefines neutral, unit = volt} 


Figure 8. Adding an Electrical Interface to a SysML Model 

| SysML ports can be overloaded ( Figure 8 Figure 8 ) to form a 
construct that resembles a connector with pins. In the model, 
we now represent an electrical circuit with a signal return. An 
Electrical Interface block can be added as an intermediate 
step; in the normal course of modeling, a high-level model 
would be generated first, and details would be added and 


defined progressively. Thus, the model now says that Power 
Controller has a powerCtrlrEIF, but we haven’t yet specified 
how many connectors we’re using, how many pins, what kind 
they are, or what they’re called. This block however does 
allow us to identify signals in the model that are going to be 
brought out. 

Connecting the signals is tricky; if we use a SysML Internal 
Block Diagram (IBD), it will create an instance of 
powerCtrlr EIF which we can wire, but that doesn’t actually 
connect powerCtrlr EIF. One approach is to redefine the pins 
on Power Controller to connect them to powerController EIF. 
Redefining pins in MagicDraw was tedious and error-prone. 

Now we can add the electrical connectors. In Figure 
9 Figure — 9, the ConnectorACPowerPlug2 inherits from 
atmlConnectorElectrical, but its matingConnectorType and 
cost properties have been redefined. One method is to say 
powerCtrlr_EIF “is a” ConnectorACPowerPlug2 and also “is 
a” ConnectorACPowerSocket2, and the pins are connected 
through again by redefinition. We’ve iterated on this concept 
here, but haven’t concluded which answer is best. Again, on 
an IBD we could have directly created instances of 
Connector ACPowerPlug2. But on the BDD we needed 

instead to create the J 1 and J2 connectors and then type them 
from the ATML-derived connector library. 



It might be desirable for SysML to report a type mismatch 
when connectors are mis-mated. Alternatively, users may 
prefer an iterative approach so that the model can be 
connected together and verified first, then come back and 
identify where mechanical adapters are needed. 

F. Capabilities, Resources, Ports, and Signals 

In the course of this work we came to understand that 
ATML does not begin test preparation by describing a 
configuration diagram. Instead it works from a list of 
requirements to be verified: the signal at certain pins is to 
meet some description with some tolerance. Then the test set 
peruses its inventory to find a capability to make such a 
measurement within the tolerance, examines wiring 
information, and configures the switch fabric to connect the 
signal to the instrument. It appears to stop short of running the 
test, and this is an area where the NASA Automation Hooks 
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Architecture can help by enabling discoverable parameters to 
be mapped to capabilities. 

The term “Port” has a specific meaning in SysML distinct 
from its specific meaning in ATML. In SysML, a port is a 
| point on a boundary. In ATML, a “Port” is a nodal collection 
of pins and their connectors that need to be joined to perform a 
capability (generally, routing signals in hardware). SysML 
has UML standard ports and flow ports , and these ports are 
used to represent variable parameters. 

| An ATML Instrument has Resources which have Ports that 
are used to supply signals or measure signals. [5] The 
Instruments themselves have Ports designating connectors and 
pins in the physical interface that Resources map to. 



Figure 10. BDD and IBD Techniques for Representing 
Capabilities and Resources 


ATML resources have ATML ports, which must be “wired” 
to the instrument ATML ports; it is also possible to describe 
that a switch controls which instrument port is wired to the 
resource. [6] ATML resources can support several 
“capabilities,” which are either signal (stimulus) or 
measurement (response) descriptions, and these must also be 
mapped to the resource ports. 

Switches were not represented in this iteration. 

G. The Information Harvest 

The Object Management Group (OMG) developed the Meta- 
Object Facility (MOF) as a means for expressing metadata 
from model languages such as SysML. The XML Metadata 
Interchange (XMI) is a means for exchanging this metadata 
using the extensible Markup Language (XML). Our approach 
to harvesting the model information from SysML was to 
process the XMI file exported from the SysML modeling tool. 

The MOF uses the notion of MOF::Classes to define 
concepts (model elements) on a meta layer. The biggest 
challenge in parsing the XMI file is to map all of the classes 
with the appropriate elements and end up with useful 
information about the described system. This is done using an 
extensive series of unique identifiers for each class and each 
element in the diagram. For example, the ACPowerPlug 
connector is defined as a packagedElement with a type of 
uml: Class and given a unique ID. The power supply itself 


(myAvBox) is also defined as a packagedElement with a type 
of umkClass and given a unique ID. Within the power supply 
element, an ownedAttribute element is defined that is given a 
type ID that references the ACPowerPlug definition. This 
relationship is shown in Figure 11 Figure 11 . 

Figure 11. XMI Snippet Showing Relationships between Block 
diagram elements and definitions 

The type of linkage shown in Figure 11 Figure 11 is 
propagated for every component of the SysML block diagram 
as well as all of the definitions and properties which are 
referenced within the diagram. Tracing through these linkages 
can become quite complicated even for this simple model. 
The XMI cannot be processed as a stream since it is not 
known ahead of time which definitions will be referenced 
elsewhere in the file and how many times they will be used. 
Thus, an XMI parser must store every unique ID and all of the 
information associated with each umkClass so that it can 
interpret the actual model of interest. 

A simple PHP-based processor was written to prove that it 
is possible to trace through the XMI linkages and harvest all of 
the necessary information by mapping all of the unique 
identifiers. This processor would require additional 

development to work for a generic block diagram and also for 
other types of SysML models, but it is clear the information 
exists in the XMI output and it could be followed with a more 
robust processor. Once these linkages are traced, they can 
easily be rearranged and output in another format such as 
ATML. 

Using library support files to contain the ATML constructs 
was transparent, as MagicDraw duplicated the information in 
the project XMI file. The use of redefinitions was not 
observed to be a problem. 

IV. Conclusion 

ATML is not merely an information format, but an 
information framework designed to support a streamlined 
workflow. It was shown here how ATML documents might 
be generated programmatically, for automatic discovery and 
collection. ATML was applied to harvest not merely data, but 
also the metadata describing configuration and control 
variables in a heterogeneous software environment. 

We also investigated how system models and ATML 
documents might be linked together. SysML models will need 
to be derived from libraries of ATML constructs so that 
information can be extracted by data-driven algorithm. A 
literal approach appears undesirable, as the ATML complex 
literal constructs are difficult to use in SysML, and ATML 
needs to transition to an ontology anyway. Thus, an abstract 
representation of ATML concepts is recommended even 
though this requires more work to strip. The exchange of 
information between ATML and SysML cannot be performed 
by a data-driven XSLT translation, an intelligent application is 
required which understands the constructs on each side. 

The techniques we explored here remain to be validated by 
the SysML user community [7], and it remains to make the 
actual conversion from SysML to an ATML document set and 
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then actually use those documents to do useful work. We 
explored two techniques for “wiring” connector pins and 
ATML resources. One used instances in an internal block 
diagram (IBD) and the other used port redefinition in a block 
definition diagram (BDD). We would like further evaluation 
by SysML users to determine which is “best.” It also remains 
to be decided whether it should be possible or not to mis-mate 
connectors in the SysML editor. 
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Automation Hooks Architecture 

API 

• Xml 

- Archive-quality 

- Enables Data-driven software architecture 


Advertised 

- Automated Discovery: Dynamic "Plug-and- 
Play" 

REST Architecture 

- Two commands: GET and PUT 

- Versatile: co-host support files and 
hyperlinks- interface definitions, 
requirements, theory of operation, 
streaming data, GUI... 


- Foundation of artificially intelligent data 
processing 

- Self-describing message format 

- Create database tables by script 
hypermedia layout 

- Insulates against layout changes 

- Coexistence of variations 

- Separate metadata for caching 


• HTTP 


- standard messaging, error messages, 
compression, security, caching 


• xmhATML (IEEE 1671) 

— standardizes units, arrays, time zone 

— Scope includes signals, instrument 
capabilities, problem reporting 

— exciting opportunities for COTS tools and 
radically different engineering workflows 


Orchestration features 

- Health and Status Rollup 

— Synchronizing and Scheduling 
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Example: Controlling a Web Power Switch 
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requires screen-scrape to ATML 

But ATML can coexist with HTML 
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<>:sl: stylesheet 
<!— created 2008 - 12 - 
<>:sl: include href=" 
<xsl: output method=' 
<xsl: template natch 
<root> 

Heuristic: <>:sl: valu 
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Parameter Pick-Listing using 
ATML c:Range (Expressing sets) 

<c:Datum xsi:type="c:string"> 

<c:Range name="valid"> 

<c:Expected comparatoR"EQ"> 

<c:Collection> 

<c:ltem><c:Datum xsi:type= M c:string M ><c:Value>OFF</c:Value></c:Datum></c:ltem> 
<c:ltem><c:Datum xsi:type= ,, c:string M ><c:Value>ON</c:Value></c:Datum></c:ltem> 
<c:ltem><c:Datum xsi:type= ,, c:string M ><c:Value>CYCLE</c:Value></c:Datunn></c:ltem> 
</c:Collection> 

</c:Expected> 

</c:Range> 

<c:Value>ON</c:Value> 

</c:Datum> 

• Associate a "valid" c:Range with the parameter 

• Express the set as a c:Collection of c:ltem 

• Issue : requires "knowing how to" compare a 
string to a collection of strings 
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Parameter Pick-Listing using 

ATML c:Range 

<c:Datum x s i : t y p e= " c : i nt e g e r" value=T' > 

<c:Range name="valid"> 

<c:Expected comparator="EQ"> 

<c:Collection> 

<c:ltem name="OFF"> <c:Datum Ksi:type= ,, c:integer" value="0"></c:Datum></c:ltem> 
<c:ltem name="ON"> <c:Datum x s i : t y p e= " c : i nt e g e r" value="1 "></c:Datum></c:ltem> 
<c:ltem name="CYCLE"><c:Datum xsi:type="c:integer" value= ,, 2 ,l ></c:Datum></c:ltem> 
</c:Collection> 

</c:Expected> 

</c:Range> 

</c:Datum> 


Choose an item. 


nw 


\ 
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L x LLJl 
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• Often, the internal representation of a parameter 
is not meaningful to the user 

• Example: enumerated list 

• ATML can carry both internal and user-oriented 
representations, with ltem@name 



"healthy", "safe", "valid": 
Expressing Multiple Ranges 


ATML schema allows 
0..1 named range 


<c:Datum xsi:type="c:integer" value="-1 "> 

<c:Range> 

<c:Expected comparator="EQ"> 

<c:Collection> 

<c:ltem><c:Collection><c: Range name’-"error l, ^<c: Expected comparator="EQ"> 
<c:Datum >csi:type= ,, c: integer" va I u e= ,i 0 T 7>’ 
</c:Expectedx/c:Rangex/c:Collection></c:ltem> 

<c:ltemxc:Collectionxc: Range name- ,, healthy"xc: Expected comparator="EQ"> 
<c:Datum X3i:type= ,, c:integer" value="-1 "/> 
</c:Expectedx/c:Range></c:Collectionx/c:ltem> 

<c:ltemxc:Collectionxc: Range name^"valid ,, xc: Expected comparator="EQ"> 
<c:Collection> 

<c:ltem name= ,, false ,, xc:Datum x s i : t y p e= " c : i nt e g e r" value="07x/c:ltem> 
<c:ltem name="true"xc:Datum x s i : t y p e= " c : i nt e g e r" value="-1 7></c:ltem> 
</c:Collection> 

</c:Expectedx/c:Range></c:Collectionx/c:ltem> 

</c:Collection> 

</c:Expected> • Need a data-driven way to roll up 

</c:Range> 

</c:Datum> 


Status 



health and safety status 





<c: Datum xsi:type="c: double" velue="-IDV> 
</c:Limit> 

. <c: Limit comp? - . "LE - 

Using-multiple^ranges, 

</c:LimitPair> 

</c:Range></c:Collectionx/c:ltem> 

<c:ltem><c:Collection><c: Range name= ,, unsafe": 

<c:Expected comparator="EQ"> 

<c:Collection> 

<c:ltem><c:Collection><c: Range name -"unsafe. low"> 
<c:SingleLimit comparator="LT"> 

<c:Datum xsi:type="c:d 0 uble" value="-107> 

</c : S i n g I e Li m it > 

</c:Rangex/c:Collectionx/c:ltem> 
<c:ltemxc:Collectionxc: Range name : ="unsafe.high , 5> 
<c:SingleLimit comparator="GT"> 

<c:Datum xsi:type="c:double" value="S07> 
</c : S i n g I e Li m it > 

</c:Range></c:Collection></c:ltem> 

</c:Collection> 

</c:Expected> 

</c:Rangex/c:Collectionx/c:ltem> 


<c 


ltemxc:Collection><c: Range nam^'Valid": 

<c: LimitPair operat 0 r= M AND"> 

<c: Limit comparat 0 r="GE"> 

<c:Datum xsi:type= M c:double" value="-207> 
</c:Limit> 


with limits 

Example 
demonstrates 
using sub- 
ranges to 
provide 
further 
interpretation 
for the 
operator 
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Example of Data-Driven Flow from 

LabVIEW to ATM L 



<tr: Parameter I D= Run. Sample Size" name= "Sample Size"> 
<!— Parameter D is a c: NonBlankStripcjT so it could be traceable 
to the softyvare variable name/— 

<tr: Desprfption>Set "Sample Size" to the target number of 
bits^to test (durationof the run).</tr:Description> 

:r: Data> 

<c: Datump<^i: type="c: double" value^'3000000" 
nonStandardUnit— ' bits > 

<c: Resolution>l</c^^solution> 

<c: Range narpe^"valid"> 

<c: umitPair operator="AND" > 

<c: Limit comparator="GE"xc: Datum xsi:type="c: double" 
value="1000"x/c: Datumx/c: Limit> 

<c: Limit comparator—' LE"xc: Datum xsi:type="c: double" 
value—' 1000000000" x/c: Datumx/c: Limit> 
</c:LimitPair> 

</c: Range> 

</c: Datum> 

</tr: Data> 

</tr: Parameter> 



The Test Results Document 


E3<tr:TestResults xmlns:tF"urn:IEEE-1636.1 :201 1 :01 :TestResults" xrnlns: c= M urn: IEEE-1 671 :2D1D:Common M xmlns:sc- 1 
urn: IEEE-P1 636. 99:01 :SimicaCommon" xmlns:xsF M http://www.w3.org/2D01/XML5chema-instance M xsi:schemaLocation 
= M urn: IEEE-1 636. 1 :201 1 :D1 :TestResults TestResults.xsd" u u i d= "{569 B634 F- 1 □ F6-4B 1 e-AD22-71 1 50201 55BF}"> 

1jJ7 Wl 1 1 m 1 1 II H I r i r 

<tr:SystemOpe rat or I D~ M j d o e User 

</tr: Personnel: 

6 <tr:ResultSet ID="_f47ac10b-58cc-4372-a567-0e02b2c3d479" name="BERT.vi" startDateTime="2012-05-30TD9:30:10"> 

! <tr:Outcome value=“Aborted7> 

| <tr:Test ID="_Bba7b81 0-9dad-1 1 dl -80b4-00c04fd430c8" name="my Space-to-Ground Link" starlDateTime=" 

2012 - 05-3 

<$> | CrtrParamatprs) Read/write "configuration" variables 
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<tr: Outcome vt 
<tr:TeetResult ID= 
<J*1'est Result ID= 
:tr:TestResult ID= 
<tr:TestResult ID= 
<tr:TestResult ID= 
:TestResult ID= 
<tr:TfeejResult ID= 
</tr:Test> 

</frRpqiiltRpt> 

<tr: 


1" name="bits" 

2" name="errors"> 

3" name="BER"> 

_4" name="Time to Acq"> 
5" name="Online"> 

6" name="Connected"> 
7" name="HW Stati*^ 


TestProgram>^~ 


Outcome is always "Aborted" 
Read-only "status" variables 

Software version 

<c: Definition version- ‘MyVersionOrRevisionNumber 11 :* 

! <c: Identification designatoF M My Operator- or Model-supplied identification of instance test-point, configuration 
diagram designator, usage, or meaning-- assigned after start-up M > 
i <c:Version>MyRevisionHistory</c:Version> 

| <c:ModelName>MyApplicationName</c:ModelName> ^ 

</c: Identifications- 
</c:Definition> 

<c:SerialNumber>MylnstanceUUID</c:SerialNumber> 

<c:ReleaseDate>2D11-12-02</c:ReleaseDate> | 

</tr:TestProgram> 

</tr:TestResults> 
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Descriptions could be 
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The Test Description Document 


<?xml version="1 .0" encoding="UTF-8"?> 

<td:TestDescription uuid="f47ac10b-58cc-4372-a567-0e02b2c3d479" xmlns:xsi=" 
http://www.w3. org/2001 /XMLSchema-instance" xmlns:td=" 
urn: IEEE-1 B7 1 . 1 :2009:TestDescription" xmlns:c="urn:IEEE-1671 :2010:Common" 
xsi:schemal_ocation="urn:IEEE-1671 .1 :2009:TestDescription TestDescription.xsd"> 


<td:UUT> 

<td:Description/> 

</td:UUT> 

<td:DetailedTestlnformation> 
<td:EntrvPoints/> 
<td:Actions> 


Static metadata is best loaded 
into tr:TestDescription 

Future work: behaviors 


<td:TestGroups> 

<td:TestGroup xsi:type="td:TestGroupUnspecifiedOrder" name="none" ID="1"> 
<td:Outcomes> 

<td:Outcome ID="1 " value="Aborted"/> 

</td:Outcomes> 


<td:ParameterDescriptions 
2td:TestResultDescriptions 
<td:ActionReferences> 

<td:ActionReference actionlD="0"/> 
</td:ActionReferences> 
</td:TestGroup> 

</td:TestGroups> 
</td:DetailedTestlnformation> 
</td:TestDescription> 


Read/write "configuration" variables 
Read-only "status" variables 
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Each domain of practice uses different data formats, 
conventions, representations, and tools making 
Interoperability and Reuse challenging 
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SysML: Maintaining Coherency 

Fundamentally, a SysML model is used to generate a set of project documents 
that are maintained "in sync" with each other 



analysis & 
simulation 
models 


documents 


spreadsheets 


system model 


operational concepts 

■ 
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adapted from SysML and MBSE: A Quick-Start Course, Georgia Tech and InterCAX 



Define "Success" for ATML 



ATML UML Model 
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Preliminary Test Readiness 

Design Critical Design Reviews 
Reviews Reviews 


ATML UML Model 


• Test = Requirements + Capabilities + Wiring 


• Maintain Documentation not Software 

• New Test Article, new Description 

• Replace an Instrument, Change a Description 

• Change Wiring, Update the Description 

• At PDR, flag requirements that can't be 
tested on deployed test sets 
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MILITARY 

READINESS 
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Current Li mit_set 
PowerLimit set 


Temperature 


Voltage_meas 
Current_meas 
(constant V, P, or I) 


Questions: how to treat ports, vs. signals, vs. interfaces: which defines the connector type 
(dare I ask about gendered connectors), which the voltage. Want units attached where 
applicable so we can understand how they're being represented. 


Requirements in SysML 


req [Package] Requirements [ Reqts j J 


■susabilityRequirements 

Application 

Id = "1" 

Text = "The power supply shall be 
suitable for the intended application." 


■^requirements 

^■sderiveRegts 
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iriveReqts 
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■sperformanceRequirements 


■^requirements 
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Packaging 

Text = "The power 


Id = "2" 
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Text= "The power supply shall 
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Peak Current 


Id = "3" 

Text = "The peak 
current shall be 
less than Ipeak" 


-r- 


■^Rationales 

N 

protect external 


components from 
damage 



■^requirements 

OutVoltage 


Id = "4" 

Text = "The output 
bus voltage shall be 
maintained 
between Voutmax 
and Voutmin, or 
below Vshutdown." 


■^requirements 

Stability 
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IN 

■sRatior^les 

n* 

protect external 


components from 


breakdowq or 


undervoltage 


partial shutdowns 



Id = "5" 

Text= "The power 
supply shall be 
stable: measure the 
impedance (freq 
sweep)" 

* - — i" ~ 


■^requirements 

TurnOnTransient 


Id = "6" 

Text = "The power 
supply output 
Current Rise time 
shall be less than 
Irate A/sec" 


■^requirements 

ReverseEnergy 


Id = "7" 

Text = "The power 
supply shall 
present Reverse 
Energy less than 
Ere/ 


^Rationales e* 

— B 

protect the power 
supply 


^Rationales [=?, I 
dont blow fuses 
at turn-on 


IN 


^Rationales r=* 

1 — B 

protect external 
components from 
back-EMF / 
reverse voltage 


■sverifys 


■sTest Cases 

OutVoltage 


Simplistic human- 
readable text 
representation 

Can be linked to the 
model 

- Model 
components can 
"satisfy" 
requirements 

- Test Cases can 
"verify" 
requirements 

MagicDraw plans to 
add support for 
SBVR 
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Quantities in ATML 


ATML provides an intriguingly 
rich mark-up for measured 
quantities 

- Standard units 

- Free-form units 

- Statistic (rms, peak...) 

- Resolution 

- Accuracy and confidence 

- Nominal Value 

- Acceptance Limits 

- Constraint Limits 

SysML uses OMG QUDV 
ontology 

- SI units only 

- Backed by an RDF/OWL 
knowledge model 


c:DatumType 


El attributes 


standai dUnit • 
nonStandardUnit 
unitGualifier 8 


; — I ^Resolution 


— ( c: DatumQuality^ E] ( ■■■ EF 


The DatumQuality group 
shall be used by any 
element that requires the 
specification of any of the 
group J s child elements. 


Base type: xs:double 
Properties: isRef 0, content 
simple 
The 

DatumQuality^Resolution 
child element shall contain 
the required resolution. 


j c ^ErrorLimits El 

Base type: c:Umit 
Properties: isRef 0, content 
complex 
The 

DatumQuality^noriJmits 
child element shall contain 
the error limits. 


\ c:Rancje [+] 

Base type: c:Umit 
Properties: isRef 0, content 
complex 

The DatumQuality/Range 
child element shall contain 
the range. 


* ;:Confidence ; 

Base type: xs:double 
Properties: isRef 0, content 
simple 
The 

DatumQuality/Confidence 
child element shall contain 
the required confidence. 


«stereotype> 

atmlDatumOualrty c 

(Element] 


+Resolution : double (0..1 ] 
+ErrorLimits : atmlLimit_c [0..1] 
+Confidence : atmlLimit_c [0..1] 
♦Range double [0..1] 



♦stereotype* 

atmIDatumTypec 

(Element] 


♦value : atmlValueType_c 



/ 


♦stereotype* 

atmlUnitAttributes_c 

(Element] 


♦standardUnit atmlStandardUnit_c (0..1] 
♦nonStandardUnit atmlNonBlankString_c [0..1 ] 
♦unitQualifier : atmlNonBlankString_c (0..1] 


♦ValueType* 

atmlValueType_c 

statistic : atmlUnitQualifier_c 


♦enumeration* 

atmlUnitQualifler_c 


mean 

rms 

peak 

peak-peak 
median 
percentilel 0 




QUDV representation for Units 



Defining a 
j custom unit 
M$US 2011) in 
MagicDraw 


standard Unit 
filter in ATM L 



<xs:pattern value="(\+ 1 \-)?\d+(\.\d*)?((E | e)(\+ 1 \-)?\d+)? *((y |z|a|f|p|n|p|u|m|c|d|h|k|M|G|T|P|E|Z|Y| 
Ki | Mi | Gi | Ti | Pi | Ei)?(F | S | C | A | V | J | eV | T | N | Hz | lx | H | m | in | ft | mi | nmi | Im | cd | Wb | g j rad | deg | ° | W | BW | Bm | P 
a | bar | B(\(\d *m?W\))? | % | pc | decade | octave | Ohm | sr | kn | K | degC | °C | degF | °F | s | min | h | L | mol)\d*((- 1 \. | /) 
(y|z|a|f|p|n|p|u|m|c|d|h|k|M|G|T|P|E|Z|Y|Ki|Mi|Gi|Ti|Pi| Ei)?(F | S | C | A | V | J | eV j T | N | Hz | lx | H | m | in | ft 
| mi | nmi | Im | cd | Wb | g | rad | deg | ° | W | BW | Bm | Pa | bar | B | % | pc | decade | octave | Ohm | sr | kn | K | degC | °C | degF 
|°F|s|min|h|L|mol)\d*)*)?" /> 
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Pins, Ports, Connectors, Wiring 


litltl [Block] Power Controller [ Power Supply def ]J 


Vin : powerCtrlr_EIF 

Nomenclature clash: "Port" 

SysML: a (logical) point on a boundary 
ATML: a nodal collection of pins and their 
connectors that need to be joined to perform 
capability (generally, routing signals in hardware) 


<£blockjs> 





Power Controller 



— •- 

constraints 



D owerOutEqn 





D owerFlow 




Vout : powerCtrlr_EIF 


PowerlnEqn = (Pin=lin * Vin) 
PowerEfficiency 


AmbiTemp : 


parts 

r^l powerCtrlr_EIF 
. wrlnConnect 


values 

: A{unit = ampere} 


WasteHeat : W 


• Consider a power controller box... 
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Note, flow ports may be 
deprecated in SysML 



Pins, Ports, Connectors, Wiring 


litltl [Block] Power Controller [ Power Supply def ]J 


Vin : powerCtrlr_EIF 
highsidej : V 


lowside i : V 


«block» 

Power Controller 


l v 


owerOutEqn 

D owerFlow 

PowerlnEqn = (Pin=lin * Yin) 
PowerEfficiency 


Vout : powerCtrlr_EIF 
highside_o : V 


AmbiTemp . C J-. p 0W erCtrlr_EIF 
. wrlnConnect 


values 

: A{unit = ampere} 


lowside o : V 


WasteHeat : W 


Ports can be over-loaded to form something 
analogous to "pins/' 


Pins, Ports, Connectors, Wiring 


bdd [Block] Power Controller [ Power Supply def 


.!■ 


: powerCtrlr_EIF 

dolockifr 

highside i : V 



Power Controller 





constraints 


lowside i : V 

H — 


PowerOutEqn 




PowerFlow 



: PowerlnEqn = (Pin=lin * Vin) 


: PowerEfficiency 


AmbiTemp : C 


Vout : powerCtrlr_EIF 
highside_o : V 


lowside o : V 


wrlnConnect 


parts 


H 


WasteHeat : W 


values 

: A{unit = ampere} 


highsidej : V 
lowside i : V 


«block* I 

powerCtrli _EIF 

parts 

: ConnectorACPowerPlug2 
: ConnectorACPowerSocket2 


highsidej : V{redefines power .unit = volt} 
lowside J : Vfredefines neutral .unit = volt} 
highside_o : V{redefines power .unit = volt} 
lowside_o : V{redefines neutral .unit = volt} 


highside_o : V 
lowside o : V 


• JPL 

recommended 
adding an 
"Electrical 
Interface" 
component. 

• The EIF allows 
the designer to 
include an 
electrical 
interface in the 
design, before 
connectors have 
been selected. 
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Pins, Ports, Connectors, Wiring 


hdd [Block] Power Controller [ Power Supply def ] J~ 


Vin : powerCtrlr_EIF 
highsidej : V 


lowside i : V 


AmbiTemp : C 


-^blocks- 

Power Controller 


co rtstrairtfs 
PowerOutEqn 
PowerFlow 

PowerlnEqn = (Pin=lin * Vin) 
PowerEfficiency 


p^jwrlnConnect 


parts 


Vout : powerCtrlr_EIF 
highside_o : V 


lowside o : V 


3 


WasteFleat : W 


values 

A{unit = ampere} 


highsidej : V 
lowside i : V 


rCtrlr_EIF "HAS A" 
ectorACPowerPlug2 and 


powe 
Conn 

Conn£ctorACPowerSocket2 


-sblocks- 

powerCtrlr_EIF 


highsidej : V{redefines power .unit = volt}! 
lowside J : V{redefines neutral .unit = voit } 
highside_o : predefines power .unit = volt} 
lowside_o — Redefines neutral .unit = volt} 


highside_o : V 


lowside o : V 



power : V 
neutral : V 


«block& 

Comic cl i A P< tfeiF I ii*j2 


parts 


ground : V J-matingConnectorType \CPowerSoch matingConnectorType} 


. cost = 5{re 


properties 


■sblock^ 

ConnectorACPowerSocket? 


parts 

cost = 6 

matingConnectorT ype 2 redefines matingConnectorT ypel 


power : V 
ground : V 
neutral : V 


Stock 

connectors can 
be pulled from a 
library, with 
inherited ATML 
metadata. 

Almost. 

The connectors 
can't be 
instances of the 
library parts, 
because the 
Power 

Controller isn't 
an instance. 
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Pins, Ports, Connectors, Wiring 


bdd [Block] Power Controller [ Power Supply def p~ 


Vin : powerCtrlr_EIF 
highsidej : V 

lowside i : V 


AmbiTemp : C 


-sblocks- 

Power Controller 


c onstraints 
PowerOutEqn 
PowerFlow 

: PowerlnEqn = (Pin=lin * Vin) 
: PowerEfficiency 


"wrlnConnect 


pads 


values 

: A{unit = ampere} 


Vout : powerCtrlr_EIF 
highside_o : V 


lowside o : V 


J3 


WasteHeat : W 


highsidej : V 
lowside i : V 


■^blocks- 

powerCtrlr_EIF 


highsidej : V{redefines power .unit = volt}] 
lowsidej : V{redefines neutral.unit = volt} 
highside_o : V{redefines power .unit = volt} 
lowside o : predefines neutral.unit = volt} 


highside_o : V 


lowside o : V 




powerCtrlr_EIF "HAS A" connectorJl and connectorJ2 


-sblocks- 

connectorJl 



power : V 
neutral : V 

pads 

ground : V matingConnectorType = Connector ACPowerSocket2{redefines matingConnectorType} 


■^blocks- 

ConnectorACPowerPlugZ 


5{redefines cost} 


pmpedies 


connectorJl "IS A" 


/PLugZ 



-^blocks- 

ConnectorACPowerSocket2 


pads 

cost J 6{redefines cost} 

igConnectorType = Connector ACPowerPlug2{redefines matingConnectorType! 


power : V 
ground : V 
neutral : V 


conn e ctorJ2 " I S A" Conn e ctorACPow e rSock e t2 


Instead, the 
power 
controller 
needs its 
own 

connectors, 
inheriting 
from the 
library parts. 

Property 
redefinitions 
are used 
liberally 
throughout. 
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A Better Place to Start 



Figure 1 - Instrument Definition Interface 


<hw:lnterface> 

<c:Ports> 

<c:Port name=" Front” /> 
<c:Port name="Back" /> 
</c: Ports> 

</hw:interface> 


Front 


Back 


Figure 2 - Resource Definition 


<Resources> 

<hw: Resource name="Resource_l"> 
<hw:interface> 

<c: Ports> 

<c:Port name="Pl"/> 
<c:Port name="P2"/> 
</c:Ports> 

</hw:interface> 

</hw:Resource> 

<hw: Resource name="Resource_ 
<hw:lnterface> 

<c: Ports> 

<c:Port name=”Pl"/> 
<c:Port name="P2"/> 
</c:Ports> 

</hw:lnterface> 

</hw:Resource> 

</Resources> 



Figure 7 - Capability Description of a SineWave 


<hw:capabil ity name=”sinewave"> 

<hw:lnterface> 

<c:Ports> 

<c:Port name=" sinewave" /> 

</c :Ports> 

</hw:interface> 

<hw:SiqnalDescription xmlns: std="http://www. ieee.orq/1641"> 

<std:siqnal name="si newavesiqnal " Out="si newave"> 

<std: Si nusoi d 
name="si newave” 

f requency="10kHz range 1kHz to IOmhz errlmt 0.1Hz res 1Hz" 
amplitude="trms IV ranqe luv to lv errlmt 0.156 ranqe IV to 10V errlmt 
</std:siqnal> 

</hw: si gnal Descri ption> 

</hw: Capability 



Figure 8 - Capability Description of an RMS Measurement 


<hw: capability name="measRMS"> 

<hw:interface> 

<c:Ports> 

<c:Port name="lnput” /> 

</c :Ports> 

</hw:interface> 

<hw:SignalDescription xmlns: std="http://www. ieee.org/1641"> 
<std:siqnal name="RMSSiqnal " in="input" out="rmsMeas"> 
<std:RMS 

name=" rmsMeas" 
ln="lnput" 

nominal ="trms ranqe luv to 10V errlmt 0.156 ranqe K 
</std:Signal> 

</hw : Si qn al Desc r i pti on> 

</hw: Capability- 



Figure 4 - Wire resources’ ports to instrument 
ports (Diagram) 



Figure 6 - Switch Definition 


<Switching> 

<hw : swi tch name= " F ron t_Bac k_swi tch "> 
<hw:interface> 

<c: Ports> 

<c:Port name="Portl" /> 

<c:Port name="Port2" /> 

<c:Port name="Resource” /> 

</c: Ports> 

</hw:interface> 

<hw : connecti ons> 


r-^-i <hw: Relaysetti ng name="Front"> 

<hw: RelayConnecti on f rom=”Portl" 

to="Resource" /> 


Ui. 


</hw: Relaysetti ng> 

<hw: Relaysetti nq name="Back"> 
f rom="Po 

to="Resource" /> 


ays 

<hw : Rel aycon nec ti on f rom=" po r 1 2 " 


</hw: Relaysetti ng> 

</hw: connecti ons> 
</hw:switch> 



A Tutorial, 
How to 
model: 

■ Interfaces 

■ Ports 

■ Resources 

■ Switches 

■ Capabilities 

■ Signals 


Figure 18 - Derived System Capabilities 















ATML Ports, Resources, Capabilities 


bdd [Package] mylnstrument [ ResourcesPorts ]J 



Didn't try switches 

Two ways to "wire:" 
instances in an IBD, vs. 
port redefinition in a BDD 



The Harvest 


bdd (Package] snIOl Instance ( Instance of the my/ 


♦block* 

snIOl : mvAvBox 


= myAvBox.partProperty 


♦block* 

mvAvBox.partPropertv : Connector ACPower 

= myAvBox.partProperty.partProperty 
= myAvBox.partProperty.partProperty 
= myAvBox.partProperty.partProperty 
cost = “8"{unit = dollarsUS201 1 } 
leadTime = "1 00000“{unit = second} 
location = 

matingConnectorType = "ACPowerSocker 
type = "ACPowerPlug" 


<xmi:XMI> 

<xmi:Documentation> ... </xmi: 
<uml:Model> ... 
<xmi:Extension> 
<xmi:Extension> 
<xmi:Extension> 
<xmi:Extension> 
<xmi:Extension> 
<sysml:Block> ... 
<sysml:Block> ... 
<sysml:Block> ... 
<sysml:Block> ... 

<j/xmi:XMI> 



Documentation 

</uml:Model> 

... <xmi:Extension> 
... <xmi:Extension> 
... <xmi:Extension> 
... <xmi:Extension> 
... <xmi:Extension> 
<sysml:Block> 
<sysml:Block> 
<sysml:Block> 
<sysml:Block> 


Model saved 

OMGXML 

Metadata 

Interchange 

(XMI) 


♦block* 

myAvBox.partPr operty.partPr operty : neutral 


ModelName = * 


♦block* 

myAvBox.partPr operty.partPr operty : ground 


ModelName = M 


♦block* 

n TY A yB px.p ar t P ro perty.partPr operty : power 


ModelName: 



<packagedElement xmi:type= , uml:Class , xmi:id='_17_0_2_ecd035c_1314997189054_814634_12767' 
name- ConnectorACPowerPlug’> .... </packagedElement> 

<packagedElement xmi:type= , uml:Class , xnni:id= , _17_0_2_ecd035c_1314998427607_193279_13954 , 
name^myAvBox^ 

<ownedAttribute xmiitype^'umkProperty' 
xmi:id= , _17_0_2_ecd035c_1314998668035_133257_14285' 

type='_17_0_2_ecd035c_1314997189054_814634_12767'/> 

</packagedElement> 


Conclusions for SysML Interoperability 


• SysML models will need to be derived from 
libraries of ATML constructs (abstract not literal 
representation) so that information can be 
extracted by data-driven algorithm. 

• Neither SysML nor ATML has a knowledge model, 
although SysML Quantities do. 

• Using redefinition to assign values to properties 
inherited from library "ATML" types was difficult. 

• Two techniques for "wiring," best not selected 



